Unsolicited Commercial Email (UCE) messages or “spam” can be malicious on several levels and are worthy of being denied further transfer on a network. An individual spam message may only be mildly “malicious” by having irrelevant content and may otherwise be benign. Nevertheless, reception of irrelevant content and the presence of the spam itself in a client mailbox are both unwanted, wasting resources and providing a degree of nuisance. Collectively, numerous spam messages from many random sources create significant loss of processing resources and provide a more intense nuisance. Worse yet, numerous spam messages can be sent in order to intentionally flood and overcome a recipient, resulting in a denial of the besieged recipient's usual services to customers and more favorable traffic. An individual spam message may also carry a virus or other intentionally malicious agent.
Conventional spam filters typically operate once an email communication (a “message” or an “email”) between network nodes has already been received by a message transfer agent (MTA) or by a client. Such filters operating within a client or within an MTA server that handles incoming mail typically address the problem of incoming spam by characterizing content. These content filters use various criteria to analyze the likely meaning of the content “payload” of a message and thereby classify the content and the message appropriately as spam or non-spam.
As shown in FIG. 1, however, this technique of designating spam by filtering content poses a burden on network resources. Mere reception of a spam email message exposes the receiving node, such as MTA 100, to certain dangers and initiates a loss of machine resources during the various processes of accepting, analyzing, routing, and/or modifying the spam message. The MTA 100 may successfully stop or at least neutralize the spam, but has expended some resources in doing so. When the next spam message arrives, perhaps from the same sender, the MTA 100 dutifully begins the filtering process all over again from scratch, thus expending even more resources to stop each spam message that comes from the same sender.
An MTA 100 is especially vulnerable if it must expend resources to filter out spam and cannot help itself from spending an unanticipated amount of resources to deal with an unexpected amount of forthcoming spam. A spam attack on such an MTA 100 can successfully force the MTA 100 to use most of its resources in a bid to filter out the spam, allowing a spam sender to effectively disable vulnerable MTAs 100. Thus, there is a need to control spam before the spam imposes on the resources of an MTA 100 or a client.